Techniques have been developed for multimedia communication involving devices in a limited local network using internal addressing and transport means, which can also be referred to as a private or home network, a LAN (Local Area Network), a residential or office network. In this description, the term “local network” is used to represent any such networks, and the term “device” represents any entity capable of media communication in a local network. The devices in a local network may include any types of entities such as fixed and wireless telephones, computers, media players or “renderers”, media servers and television boxes, the latter also called “STB” (Set Top Box).
UPnP (Universal Plug-and-Play) is a technology for establishing standardised device protocols for communication in a local network between different devices that may use different access technologies, operating systems, programming languages, format standards and communication protocols. Further, DLNA (Digital Living Network Alliance) is a technology for acquiring, storing and accessing digital media content in devices of a local network. The UPnP protocol is utilised by DLNA as an underlying protocol for communication between DLNA-enabled devices within local networks. Such DLNA devices are generally capable of using HTTP (Hyper Text Transport Protocol) as a basic transport mechanism for transfer of media in a local network. In addition, RTP (Real Time Protocol) can also be used for media transport in the local network. UPnP supports a process called “discovery” in which a device can join a local network and exchange capabilities and share services with other devices in the network.
A network architecture called IMS (IP Multimedia Subsystem) has been developed as a platform for handling and controlling multimedia services and sessions. In order to provide IMS-based services for devices in a limited local network and to enable multimedia communication with entities outside the local network, a gateway commonly called “HIGA” (Home IMS Gateway) has been devised as a solution where an IMS core is used for establishing sessions with external entities.
A local network typically also has a gateway function for external media transport to and from the local network, often called the “RGW” (Residential Gateway) or “HG” (Home Gateway), the latter being used by the standard organisation HGI (Home gateway Initiative). The HIGA can be regarded basically as an RGW or HG with added IMS functionality. In this description, the term HIGA will be used to represent a gateway with IMS functionality.
UPnP also defines a Remote Access Architecture RAA, enabling a remote UPnP device located outside the local network to communicate with UPnP devices located within the local network. In particular, the RAA specifies how to provision and configure parameters required for enabling remote access connections between entities having a Remote Access Server RAS and a Remote Access Client RAC, respectively, generally referred to as a UPnP RA procedure.
FIG. 1 illustrates a typical logic structure in a remote device 100 and in a local gateway 102 of a local network, respectively, for enabling remote access to local devices in the network (not shown) according to the UPnP RA procedure. The local gateway 102 may be a HIGA, RGW and/or HG. A Remote Access Client “RAC” 100a has been configured in the remote device 100 and a corresponding Remote Access Server “RAS” 102a has been configured in the local gateway 102, which can be done when both are present in the local network since RAC 100a and RAS 102a should be configured and synchronized with matching profiles.
The RAC 100a comprises a Remote Access Discovery Agent “RADA” 100b, and the RAS 102a comprises a corresponding Remote Access Discovery Agent “RADA” 102b, both being configured to exchange discovery or “pairing” messages between the two entities 100 and 102. The RAC 100a further comprises a Remote Access Transport Agent “RATA” 100c and the RAS 102a comprises a corresponding Remote Access Transport Agent “RATA” 102c, both being configured to establish a transport channel for media between the two entities 100 and 102. Effectively, the RATAs 100c, 102c will act as opposite end points for signalling and media communication of the remote access.
In FIG. 2, a local network 200 comprises various different devices in a family residence or an office, in this example including a wireless telephone, a fixed telephone, a TV set, a laptop computer and a media server. The local network 200 also includes a gateway for external communication, in this case including the functions of a HIGA 200a and an RGW 200b, the latter typically having a NAT (Network Address Translation) function and a local DHCP (Dynamic Host Configuration Protocol) server for managing local IP addresses of the devices which are valid only within the local network 200, as is well-known in the art. In practice, the HIGA 106 may be physically integrated in the RGW 102 although logically considered as individual functional units. Further, a media server for storage of media content may also be integrated in the local network gateway which is often denoted a “DMS” (DLNA Media Server) in which a content directory may be maintained for all media content stored in the network.
FIG. 2 also illustrates an opposite local network 202 which has a similar structure and entities as network 200, although not shown in detail here. Techniques have been developed to enable access to media from a remote device or a remote network, such that a device in network 202 can thus remotely access media that is stored in a device at network 200.
According to known solutions, the HIGA 200a performs IMS signalling with a corresponding HIGA or an IMS-enabled device in network 202 over an IMS core 204, as shown by an action 2.1, in order to establish multimedia communication between the two local networks 200, 202. Typically, a VPN (Virtual Private Network) tunnel is set up between RGW 200c and a corresponding entity in network 202, as shown by an action 2:2. Thereby, a user of a device (not shown) in network 202 is able to browse for media content being stored in network 200, e.g. in the shown media server 200c, over the established VPN tunnel, as shown by an action 2:3. If some media content in server 200c is selected by the browsing user in network 202, a session for media transfer over the RGW 200b is executed, as shown by an action 2:4.
However, the known solutions for remote access require that a connection is established between the two local networks, typically a VPN tunnel, before a remote user is able to browse for content in the local network of interest and see what content is available therein. Typically, the browsing can be made in the above-mentioned content directory in a DMS if implemented in the gateway of network 200. This procedure becomes an even greater burden when the user wants to see available content in several local networks, e.g. in the homes of various friends.
Another restriction is that the current solutions for remote access offer access control depending on the accessing device only, such that either all or nothing of the content stored in a local network is made available to a browsing remote device. As a result, the entire media server in a home must be shared with another user, if at all, and selective sharing of only some content is thus not enabled in current solutions. Further, when establishing a connection between devices in two opposite local networks, the risk of collision between local network addresses arises when potentially overlapping private address spaces are used within the networks. There is typically no coordination of address allocation between different local networks, which is commonly handled independently by DHCP servers in the respective networks.